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Foreword 


NHTSA’s Automotive Cybersecurity Research Program 

Based on a systems engineering approach, the National Highway Traffic Safety Administration 
established five research goals to address cybersecurity issues associated with the secure 
operation of motor vehicles equipped with advanced electronic control systems. This program 
covers various safety-critical applications deployed on current generation vehicles, as well as 
those envisioned on future vehicles that may feature more advanced fonns of automation and 
connectivity. These goals are: 

1. Build a knowledge base to establish comprehensive research plans for automotive 
cybersecurity and develop enabling tools for applied research in this area; 

2. Facilitate the implementation of effective industry-based best-practices and voluntary 
standards for cybersecurity and cybersecurity infonnation sharing forums; 

3. Foster the development of new system solutions for automotive cybersecurity; 

4. Research the feasibility of developing minimum perfonnance requirements for 
automotive cybersecurity; and 

5. Gather foundational research data and facts to inform potential future Federal policy and 
regulatory decision activities. 


This report 

The primary objective of the work described in this report is to review the National Institute of 
Science and Technology (NIST) guidelines and foundational publications from an automotive 
cybersecurity risk management stand-point. The NIST approach is often used as a baseline to 
develop a more targeted risk management approach for the specific use cases and issues in 
specific industries and sectors. This report can be considered as a primer that establishes a 
baseline conceptual understanding of the NIST approach for the readers and a common 
vocabulary for discussing risk management for the automotive sector. Additional work would be 
needed to more effectively apply this framework to the automotive sector. 

This publication is part of a series of reports that describe our initial work under the goal of 
facilitating cybersecurity best practices in the automotive industry (Goals 1 and 2). The 
information presented herein increase the collective knowledge base in automotive 
cybersecurity; help identify potential knowledge gaps; help describe the risk and threat 
environments; and help support follow-on tasks that could be used to establish security 
guidelines. 
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1.0 Objective 


The obj ecti ve of thi s paper i s to revi ew the N ati onal I nsti tute of Standards and Technol ogy gui del i nes and 
foundational publications for cybersecurity risk management. This paper is a primer that provides an 
examination of cybersecurity risk management topics and is intended to provide readers with a better 
understandi ng of the NI ST approach to cybersecurity. Thi s NI ST approach i s often used as a basel i ne i n 
i ndustri es and sectors to devel op a more targeted ri sk management approach for the sped f i c use cases and 
i ssues i n those i ndustri es and sectors. This paper wi 11 establ i sh for readers a basel i ne conceptual 
understanding of the NIST approach with foundational documents to establish a common vocabulary for 
di scussi ng ri sk management for the vehi cl e sector. 


1.1 Background 

NIST Cybersecurity Risk Management Framework (RMF) and Other Government Agency/Sector 
Use 

TheNIST Federal Information Processing Standards (FI PS) 199, Standards for Security Categorization of 
Federal Information and Information Systems and the NIST Special Publication (SP) 800-series provide 
the foundational baseline for federal cybersecurity best practices, as well as a foundation for most 
industries. FIPS 199 and several SP 800-series, including SP 800-60, SP 800-30, SP 800-37, SP 800-39, 
and SP 800-53, were used to develop this paper. In particular, NIST SP 800-37, Guide for Applying the 
Risk Management Framework to Federal Information Systems, developed by the Joint Task Force 
Transformation Initiative Working Group, transforms the traditional Certification and Accreditation 
(C&A) process into the six-step Risk Management Framework (RMF). 1 Risks are measured through 
evaluation of the probability of the vulnerability being exploited, as well as the severity to the system, 
organization, public, etc. if the system is compromised. 

The f ol I owi ng are exampl es of NI ST support to other government agency i ni ti ati ves to tai I or the SP 800- 
seri es and RM F for thei r use. M any of these documents shoul d assi st the vehi cl e sector i n tai I ori ng the 
NI ST RM F standards to meet thei r needs: 

1. U.S. Department of Energy Electricity Subsector Cybersecurity Risk Management Process 
(March 2012) - This electricity subsector cybersecurity Risk Management Process (RMP) 
guideline was devel oped by the Department of Energy (DOE), in collaboration with NIST and the 
North American Electric Reliability Corporation (NERC). Members of industry and utility- 
sped f i c trade groups were i ncl uded i n authori ng thi s gui dance, desi gned to be meani ngf ul and 
tai I ored for the el ectri ci ty sector. The pri mary goal of thi s gui del i ne i s to descri be a Ri sk 
Management Plan (RMP) that is tuned to the specific needs of electricity subsector organizations. 


i 

NOTE: A key step for the Vehicle Sector is “Threat Model/Use Case,” so this step was added. The original RMF Step 5 “Authorize” applies to 
Federal IT systems and not Vehi decontrol systems, so that was removed. 
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NIST SP 800-39, Managing Information Security Risk, provides the foundational methodology 
for thisdocument. The NIST Interagency Report (NISTIR) 7628, Guidelines for Smart Grid 
Cyber Security, and the NERC Critical Infrastructure Protection (CIP) Cyber Security standards 
further refine the definition and application of effective cybersecurity for all organizations in the 
electricity subsector. 

2. U.S. Nuclear Regulatory Commission (NRC) Regulatory Guide(RG) 5.71, Cyber Security 
Programs For Nuclear Facilities (January 2010) - This regulatory guide provides an approach 
that the NRC staff deem acceptable for complying with the Commission’s regulations regarding 
the protection of digital computers, communications systems, and networks from a cyber-attack 
as defined by 10CFR73.1. RG 5.71 describes a regulatory position that promotes a defensive 
strategy consisting of adefensive architecture and a set of security controlsbased on standards 
provided in NIST SP 800-53 Rev. 3, Recommended Security Controls for Federal Information 
Systems and Organizations, and NIST SP 800-82, Guide to Industrial Control Systems (ICS) 
Securi ty. NI ST SP 800-53 and SP 800-82 are based on wel I -understood cyber threats, ri sks, and 
vul nerabi I i ti es. RG 5.71 di vi des the above-noted securi ty control s i nto three broad categori es: 
technical, operational, and management. 

3. NIST Special Publication 800-82, Guide to I ndustrial Control Systems (ICS) Security: 
Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems 
(DCS), and other control system configurations, such as Programmable Logic Controllers 
(PLC) (June 2011) - Thisdocument provides guidance for establishing secure ICS. These ICS, 
which include SCADA systems, DCS, and other control system configurations such as skid- 
mounted PLC, are often found in the industrial control sectors. ICS are typically used in 
industries such as electric, water and wastewater, oil and natural gas, transportation, chemical, 
pharmaceutical, pulp and paper, food and beverage, and discrete manufacturing (e.g., automotive, 
aerospace, and durable goods.). NIST developed SP 800-82 in cooperation with the public and 
pri vate sector ICS communi ty to devel op sped f i c gui dance on the appl i cati on of the securi ty 
controls in NIST SP 800-53 Rev. 3, Recommended Security Controls for Federal Information 
Systems and Organizations, to ICS. 

4. American Public Transportation Association (APTA) Control & Communications Security 
Working Group (CCSWG) Recommended Practice, Securing Control and Communications 
Systems in Transit Environments- The foil owing related risk assessment documents have/are 
being developed: 

a. Part 1: Elements, Organization and Risk Assessment/Management (July 2010) - This 
document addresses the security of the foil owing passenger rail and/or bus systems: 
SCADA, traction power control, emergency ventilation control, alarms and indications, 

f i re/i ntrusi on detecti on systems, trai n control /si gnal i ng, fare col I ecti on, automati c vehi cl e 
location (AVL), physical security feeds (e.g., CCTV, access control), public information 
systems, public address systems, and radio/wireless/related communication. 

b. Part 2: Security Plan Development, Execution and Maintenance (Draft Complete) - 
Thisdocument introduces Security Zone Architecture (Defense in Depth), per the 
Department of Homeland Security, adapting DHS manufacturing security zones to 
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Transit. It defines generic transit zones and outlines the Highest Consequence Zones 
(signaling, fire/life safety), and partitions zones and lists security controls for the Highest 
Consequence Zones, applying the appropriate NIST 800-53 security controls, 
c. Part 3: Rail Vehicle Zone Concept (TBD) - This document will descri be protecti ng 
Operationally Critical Zones (Traction Power SCADA, etc.), and rail vehicles (vital 
propulsion, brakes, maintenance, passenger Wi-Fi, and train to wayside 
communications). Part 3 wi 11 include “Attack Modeling” (Security Anal ysis Procedure) 
to be worked on by system integrators, equipment vendors and transit agencies. 

5. Catalog of Control Systems Security: Recommendations for Standards Developers (April 
2011) - This catalog presents a compilation of practices that various industry bodies have 
recommended to increase the security of control systems from both physical and cyber-attacks. 
The recommendations in this catalog are grouped into 19 families, or categories, that have similar 
emphasis. The recommendations within each family are displayed with a summary statement of 
the recommendation, supplemental guidance or clarification, and a requirement enhancements 
statement providing augmentation for the recommendation under special situations. This catalog 
is not limited for use by a specific industry sector. All sectors can use it to develop a framework 
needed to produce a sound cybersecurity program. The organization of each recommendation is 
based on NIST 800-53 Rev. 3, Recommended Security Controls for Federal Information Systems 
and Organizations, but modified to convey control system language. 

6. ARINC Technical Application Bulletin: ARINC Abn035A, Considerations for the 

I ncorporation of Cyber Security in the Development of I ndustry Standards- In the air 
transport industry, theARINC Airlines Electronic Engineering Committee (AEEC) standards and 
specifications support the design and development of safe aircraft systems, and must include 
security considerations. The purpose of thisTechnical Application Bulletin (TAB) isto provide 
gui del i nes to groups prepari ng A Rl N C Standards. These gui del i nes cover cybersecuri ty 
provi si ons to be i ncl uded i n new A Rl N C Standards. The TA B provi des vi si bi I i ty i nto what 
standards are currently being worked on and what security control families should be considered. 
The detailed security gui deli nes are loosely aligned with the control families of NIST SP 800-53. 


See Appendix A for more information and web links for documents referenced. 


2.0 Vehicle Sector Cybersecurity Issues and Activities 

2.0.1 Vehicle Sector Cybersecurity Issues and Challenges 

The modern vehi cl e i s enteri ng a peri od of unprecedented changes and chal I enges. Long passed are the 
days when switching from battery to magneto constituted engine ignition control. Vehicles today are 
complex machines which can contain over 60 embedded electronic control units(ECUs), networks to 
support these units, and a host of external interfaces, both wired and wireless. Wired interfaces can 
include USB, CD/DVD, and SD cards. Wireless interfaces can include Bluetooth, Wi-Fi, radio frequency, 
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near f i el d communi cati ons (N FC), Gl obal System for M obi I e Communi cati ons (GSM )/Code Di vi si on 
Multi pie Access (CDMA), and Universal Mobile Telecommunications System (UMTS). The wireless 
i nterfaces can be used to support a host of features, i ncl udi ng remote ti re pressure monitori ng, tel ematics, 
and smart key keyless entry/ignition. Other systems that will be appearing in the near future will be 
vehicle-to-vehicle(V2V) communications, and V2X communi cati ons that promise to offer tremendous 
benefitsfor efficiency, comfort, and driving safety. The continuing trend in vehicle sector architecture is a 
shift from an isolated closed loop structure to more and more open systems. 

Driven by consumer demand, the amount of embedded systems and the code to support them wi 11 
continue to grow. By utilizing the embedded systems, manufacturers can provide upgrades and premium 
functionality more readily and cost effectively. In a 2011 EETimes article, 2 IBM’s Meg Selfe, a vice 
president for complex and embedded systems at IBM Rational, remarked that the Chevrolet Volt uses an 
estimated 10 million lines of code running on about 100 ECUs. In comparison, atypical 2009 model used 
six mi 11 i on I i nes of code and a 2005 model used about 2.4 mi 11 i on I i nes of code. 

Increasing feature sets, interconnectedness with internal and external networks, and increasing complexity 
can al so i ntroduce securi ty fI aws that may be expl oi tabl e by vari ous adversari es such as “ scri pt ki ddi es,” 3 
dishonest drivers, criminals/terrorists, corporate espionage, and even the vehicle’s owner. 

Compromi se of vehi cl e cyber control I ed systems can occur i n many ways, i ncl udi ng del i berate 
cybersecurity attacks, owners of the system changing default parameters, physical damage to network 
components, radio frequency interference, etc. 


2.0.2 Vehicle Sector Cybersecurity Activities 

SAE International Vehicle Electrical System Security Committee 

TheSAE International Vehicle Electrical System Security Committee is developing and maintaining 
Recommended Practices and Information Reports in the area of vehicle electrical systems’ security. The 
commi ttee’s scope i s on-board vehi cl e el ectri cal systems that affect vehi cl e control or otherwi se act 
contrary to the occupants’ i nterests if the systems are mani pul ated by an attacker. The goal s of the 
committee are: 

• To i dentify and recommend strategi es and techni ques rel ated to preventi ng and detecti ng 
adversarial breaches, and 

• Mitigating undesirable effects if abreach isachieved. 


2 

Merritt, R. (2011, May 4). IBM tel I s story behind Chevy Volt design. San Jose, CA: EE Times. Retrieved from 
w w w. eet i mes. com/docu ment. asp?doc_i d=1259444 

3 

In hacker culture a script kiddie is an unskilled person who use scri pts(i.e., programs) developed by others to attack computer 
systems and networks. 
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The group i s chartered to cl assi fy attack methods, propose preventati ve strategi es, def i ne I evel s of 
security by criticality of system type, and identify architecture-level strategies for mitigating attacks. 
Committee participants include OEMs, suppliers, consulting firms, government entities, and other 
interested parties. 

Specifically, the SAE Vehicle Electrical System Security Committee has created a task force (TF), 
Automotive Security Guidelines and Risk Development TF 2. One of the initial steps will be to examine 
vari ous potenti al basel i ne documents from among exi sti ng standards. Perti nent standards that have been 
i denti fi ed at thi s ti me i ncl ude: 

• NIST Special Publication (SP) 800-series(e.g., 800-30, 800-37, 800-39, 800-82, and 800-53); 

• NIST FIPS 199, Standards For Security Categorization of Federal Information And Information 
Systems; 

• NIST FIPS 200, Mini mum Security Requirements For Federal Information And Information 
Systems); 

• I SO 26262, Road Vehi cl es — Functi onal Safety; 

• E-Safety Vehicle Intrusion Protected Applications (EVITA) 4 Security Requirements Analysis; 

• RTCA DO-178C, Software Considerations In Airborne Systems And Equipment Certification; 
and 

• FAA Cybersecurity Certification and Accreditation (C&A) process, documents, and templates. 

Once a basel i ne i s chosen, the sub-committee wi 11 devel op an appropri ate approach for ri sk assessment 
and categorization of vehicles. The guideline may include elements of other existing standards and a 
definition of areference architecture including communications networks and an exhaustive set of vehicle 
use cases. Methods, tools, artifacts, potential integration of security into exi sting automotive safety 
approaches, e.g., overlay, and integration with ISO 26262, will also be included. 


3.0 Application of the NIST Risk Management Framework 

3.0.1 Overview of NIST Risk Management Framework 

One key el ement to focus thi s task i s the use of accepted standards for securi ty assessment i n a I i fecycl e 
process. The approach used in the federal government and many private industry Critical Infrastructure 
(Cl) sectorsisthe NIST Security Life Cycle Approach for risk assessment, security planning and 
implementation, and ongoing monitoring of fielded systems. Figure 1 below depicts the steps and control 


4 

EVITA. (2011, April 15). E-safety vehicle intrusion protected applications. (Web page. Fact sheet). Brussels: European 
Commission - Information Society and Media DG . Retrieved from http://evita-proiect.org/EVITA factsheet.pdf 
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documents in the NIST Risk Management Framework (RMF) Security Life Cycle and the NIST standards 
used in the process. 5 


Risk Management Framework 


MONITOR 
Security State 


Continuously track changes to the 
information system that may affect 
security controls and reassess 
control effectiveness. 


AUTHORIZE 
Information System 


Determine risk to organizational 
operations and assets, individuals, 
other organizations, and the Nation; 
if acceptable, authorize operation. 


Starting Point 


CATEGORIZE 
Information System 


Define criticality/sensitivity of 
information system according to 
potential worst-case, adverse 
impact to mission/business. 


Security Life Cycle 


ASSESS 
Security Controls 


SELECT 
Security Controls 


Select baseline security controls; 

apply tailoring guidance and 
supplement controls as needed 
based on risk assessment. 


IMPLEMENT 

Security Controls 


Implement security controls within 
enterprise architecture using sound 
systems engineering practices; apply 
security configuration settings. 


Determine security control effectiveness 
(i.e., controls implemented correctly, 
operating as intended, meeting security 
requirements for information system). 


Figure 1: NIST Risk Management Framework (RMF) 


The RM F provi des a di sci pi i ned and structured process that i ntegrates i nf ormati on securi ty and ri sk 
management activities into the system development lifecycle. The RMF steps are: 

1. Categorize the information system and the information processed, stored, and transmitted by that 
system based on an impact analysis. 

2. Select an initial set of baseline security controls for the information system based on the security 
categorization, tailoring and supplementing the security control baseline as needed based on an 
organizational assessment of risk and local conditions. 

3. I mpl ement the securi ty control s and descri be how the control s are empl oyed wi thi n the 
information system and its environment of operation. 


5 NIST Risk Management Framework Presentation slides, http://csrc.nist.gov/groups/SMA/fisma/document^risk-managernent-frama/vork- 
2009.pdf 
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4. Assess the securi ty control s usi ng appropri ate assessment procedures to determi ne the extent to 
which the controls are implemented correctly, operating as intended, and producing the desired 
outcome with respect to meeting the security requi rements for the system. 

5. Authorize information system operation based upon a determination of the risk to organizational 
operations and assets, individuals, other organizations and the Nation resulting from the operation 
of the i nf ormati on system and the deci si on that this risk is acceptabl e. 

6. M onitor the security control s i n the i nf ormati on system on an ongoi ng basi s, i ncl udi ng assessi ng 
control effectiveness, documenting changes to the system or its environment of operation, 
conducting security impact analyses of the associated changes, and reporting the security state of 
the system to designated organizational officials. 

The Risk Management Framework and associated RMF tasks apply to both information system/control 
system owners and common control providers The RMF supports the selection, development, 
implementation, assessment, and ongoing monitoring of common controls inherited by organizational 
information/control systems. Execution of the RMF tasks by common control providers, both internal and 
external to the organi zati on, hel ps to ensure that the securi ty capabi I i ti es provi ded by the common 
controls can be inherited by information system owners with a degree of assurance appropri ate for their 
information protection needs. This approach recognizes the importance of security control effectiveness 
wi thi n i nf ormati on systems and the i nf rastructure supporti ng those systems. 

Si nee the tasks i n the RM F are descri bed i n a sequenti al manner, organi zati ons may choose to devi ate 
from that sequential structure in order to be consistent with their established management and system 
devel opment I i f e cycl e processes, or to achi eve more cost-eff ecti ve and eff ici ent sol uti ons wi th regard to 
the execution of the tasks. Organizations may also execute certai n RMF tasks in an iterative manner or in 
different phases of the system development lifecycle. For example, security control assessments may be 
carried out during system development, system implementation, and system operation/maintenance (as 
part of continuous monitoring). 

Organi zati ons may al so choose to expend a greater I evel of effort on certai n RM F tasks and commi t fewer 
resources to other tasks based on the I evel of maturity of selected processes and activities within the 
organi zati on. Si nee the RM F i s I i f e cycl e-based, there will be a need to revi si t vari ous tasks over ti me, 
dependi ng on how the organi zati on manages changes to the i nf ormati on systems and the envi ronments i n 
which those systems operate. Managing information security-related risks for an information system is 
viewed as part of a larger organization-wide risk management activity carried out by senior leaders. The 
RMF must simultaneously provide a disciplined and structured approach to mitigating risks from the 
operation and use of organizational information systems, and theflexibility and agility to support the core 
missions and business operations of the organi zati on in highly dynamic envi ronments of operation. 


3.0.2 Application of the NIST RMF to the Vehicle Sector 

This secti on uses NI ST SP 800-37, SP 800-39 and SP 800-30 to tai I or the appl i cabl e steps of the RM F for 
the vehi cl e sector. Excerpts from the NI ST documents are provi ded bel ow. The steps were modi f i ed to 
hi ghl i ght the i importance of how certai n topi cs coul d be used i n the areas of requi rements of Threat 
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Models, Security Categorization, Security Reference Architecture, and Security Test and 
Evaluation/Penetration Testing. A key step for the vehicle sector is “Threat Model/Use Case,” sothisstep 
was added. The original RMF Step 5, “Authorize,” applies to Federal IT systems and not vehicle control 
systems, so that step was removed. Figure 2 depicts the modified RMF framework for the vehicle sector. 


Risk Management Framework 


Step 1 
ASSESS 

Threat Model/ 
Use Case 


SP 800-137 


Step 6 MONITOR 
Security State 


Continuously track changes to the 
information system that may affect 
security controls and reassess 
control effectiveness. 


Starting Point 

FIPS 199/SP 800-60 


Step 2 

CATEGORIZE 
Information System 


Define criticality/sensitivity of 
information system according to 
potential worst-case, adverse 
impact to mission/business. 


Security Life Cycle 


SP 800-39 


SP 800-53A 


Step 5 ASSESS 
Security Controls 


FIPS 200 ISP 800-30 


Step 3 SELECT 
Security Controls 


Select baseline security controls; 

apply tailoring guidance and 
supplement controls as needed 
based on risk assessment. 


SP 800-70 


Step 4 
IMPLEMENT 

Security Controls 


Determine security control effectiveness 
(i.e., controls implemented correctly, 
operating as intended, meeting security 
requirements for information system). 


Implement security controls within 
enterprise architecture using sound 
systems engineering practices; apply 
security configuration settings. 


i\iisr 


NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY 


Figure2: Modified NIST Risk Management Framework for the Vehicle Sector 


RMF Step 1: Assess Threat Model/Use Cases 

1-1: Threat Assessment/Use Cases - Threat sources cause events having undesirable consequences or 

adverse iimpacts on organizational operations and assets, individuals, other organizations, and the 
Nation. Threat sources include: (1) hostile cyber/physical attacks; (2) human errors of omission or 
commission; or (3) natural and man-made disasters. For threats due to hostile cyber-attacks or 
physi cal attacks, organi zati ons provi de a sued net characteri zati on of the types of tacti cs, 
techniques, and procedures employed by adversaries that are to be addressed by safeguards and 
countermeasures. Next, organi zati ons typically identify aset of representative threat “Use Cases” 
(e.g., call center, maintenance/diagnostics, telemetry). Thisset of use cases provides guidance on 
the level of detail with which the events are descri bed. Organi zati ons also identify conditions for 
when to consider threat events in risk assessments. For example, organizations can restrict risk 
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assessments to those threat events that have actually been observed (either internally or externally 
by partners or peer organizations) or alternati vely, spedfy that threat events descri bed by credi bl e 
researchers can al so be consi dered. 

I n vehicle scenarios of the not too distant future, breaches made to the security of vehicle control 
systems or f uncti ons coul d I ead to possi bl e i ssues for stakehol ders i n these four mai n areas: 

• Pr i vacy - unwanted or unauthori zed acqui si ti on of data pertai ni ng to: 

o Vehi cl e or dri ver acti vi ti es, 

o Vehi cl e or dri ver i denti ty data, and 

o Vehi cl e or sub-system desi gn and i mpl ementati on. 

• Financial - unwanted or unauthorized commercial transactions, or access to vehicle; 

• Operational -unwanted or unauthorized interference with on-board vehicle systems 
or Car2X communications that may impact the operational performance of vehicles 
and/or ITS (without affecting physical safety); and 

Safety - unwanted or unauthorized interference with on-board vehicle systems or 
Car2X communications that may impact the safe operation of vehicles and/or ITS. 

RMF Step 2: Categorize Vehicle Systems 

2-1: Security Categorization - Categorize the vehicle system/sub-systems, and document the results 

of the security categorization in the security plan. 

The security categorization process is carried out by the information system/control system owner 
and information owner/steward in cooperation and collaboration with appropriate organizational 
officials (i.e., senior leaders with mission/busi ness function and/or risk management 
responsi bi I i ti es). The securi ty categori zati on process i s conducted as an organi zati on-wi de 
activity, taking into consideration the enterprise architecture and the information security 
architecture. The security categorization allows the constituent subsystems to receive a separate 
allocation of security controls from NIST SP800-53A, Guide for Assessing the Security Controls 
in Federal Information Systems and Organizations, instead of deploying higher-impact controls 
across every subsystem. 

Tabl e 1 shows an exampl e of a Securi ty Categori zati on usi ng FI PS 199 and SP 800-60 for 
modern vehi cl es usi ng an automated Excel spreadsheet (Thi s tabl e was used for an Avi ati on FI PS 
199 and it was tailored for vehicles). The Security Categorization provides FIPS 199 
Confidentiality- Integrity-Avail ability and FIPS199 Overall System Impact Levels(High, 
Medium, and Low). 

Tablet Modern VehicleSecurity Categorization Example Using NIST SP 800-60 and FIPS199 
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NHTSA Vehicle Data Sensitivity Analysis (DAST) Tool 


Volpe National Transportation Systems Center Cambridge MA 


Vehicle at 


Phases of Vehicle Trip 


Vehicle 

Parked 

(e.g. 

Garage) 


Vehicle at 
Rest 
(Traffic 
Light) 


Vehicle 

Maint. 

(Dealer/L 

ocal 

Garage) 


Vehicle at 
65MPH 
(highway) 


20MPH 
on a 
major 
highway 
(stop/go 
traffic) 


CONFIDENTIALITY - A loss of 


FIPS 199 Confidentiality 
Integrity-Availability 


confidentiality is the unauthorized 
disclosure of information. 

INTEGRITY - A loss of integrity is the 
unauthorized modification or 
destruction of information. 


AVAILABILITY - A loss of availability is 
the disruption of access to or use of 
information or an information system. 


Powertrain 


Throttle Valve Data 












CAN Bus Data message for the 
PCM (Powertain Control 

Module) 


L 

L 

L 

L 


L 

L 

L 



Apdaptive Cruise Control Data 



L 

L 

L 


L 

L 

L 



Local Interconnect Network 
(LIN) Steering Wheel data 


L 

L 

L 

L 

L 

L 

L 

L 



Antilock Brake System (ABS) 
Brake-by-Wire data (via 

FlexRay) 



L 

L 

L 


L 

L 

L 




Vehicle Safety 






M 

M 


M 

M 


M 

M 


M 

M 


Onboard Diagnostics (OBD II) 
emissions data 


L 

L 


L 

L 


L 

M 

M 





M 

M 

TPMS data (via Bluetooth) 


L 

L 

L 

L 

L 


L 

M 

M 




L 

M 

M 

Firmware-Updates-Over-The- 
Air (FOTA) Remote Diagnostics 
Data 


L 

L 


L 

L 







L 


L 


Airbag Control Unit Data 


L 

L 


L 

L 

L 

L 

L 





L 

M 

M 

GPS Data 


M 

M 

M 


M 


L 

L 









Table 1: Modern VehicleSecurity Categorization Example Using NIST SP 800-60 and FI PS 199 

(Continued) 
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Comfort System 

Local Interconnect Network 
(LIN) Climate Control Data 


L 

L 


M 

M 

M 

L 


L 


M 

M 

L 

M 

M 

Door Control Unit Data (Power 
doors) 


L 



M 

M 

M 

L 




M 

M 

L 

M 

M 

Infotainment 

MOST (Media Oriented 

Systems Transport) audio 
amplifier data 





M 

M 

M 

L 

L 

L 

L 

M 

M 

L 

M 

M 

Personal Identity Info (Pll) 





1 


L 

L 


L 





M 

M 

Internal connectivity data (for 
mobile devices) 


L 

L 

L 

M 

M 

M 

L 


L 

L 

M 

M 

L 

M 

M 


Telematics 


GPS Data for Emergency 
Response 


M 

M 

M 

M 

M 

M 




Map Navigation data 


L 

L 

L 

M 

M 

M 

L 

L 

L 


FIPS 199 Confidentiality- 
Integrity - Availability 





M 

M 




FIPS 199 Overall System 
Impact Level: 

L 




2-2: Information System Description - Describe the information/control system (including system 

boundary) and document the description in the security plan. 

Descri pti ve i nformati on about the i nf ormati on/control system i s documented i n the system 
identification section of the security plan, included in attachments to the plan, or referenced in 
other standard sources for information generated as part of the system development lifecycle. 
Duplication of information is avoided whenever possible. The level of detail provided in the 
security plan is determined by the organization and is typically commensurate with the security 
categori zati on of the i nf ormati on system. I nf ormati on may be added to the system descri pti on as 
it becomes avai I abl e duri ng the system devel opment I ife cycl e and executi on of the RM F tasks. 


Examples of the Information System Description section include: 

o F’urpose, f uncti ons, and capabi I i ti es of the i nf ormati on system and mi ssi ons/busi ness 
processes supported; 

o Resul ts of the securi ty categori zati on process for the i nf ormati on and i nf ormati on system; 
o Types of information processed, stored, and transmitted by the information system; 
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o 


Boundary of the information system for risk management and security authorization 
purposes; 

o Architectural description of the information system including network topology; and 
o Hardware and firmware devices included within the information system. 


RMF Step 3: Select Security Controls 

3-1: I dentify Vulnerabilities-1dentify vulnerabiIitiesand predisposing conditionsthat affect the 
I i kel i hood that threat events of concern resul t i n adverse i impacts. 

The pri mary purpose of vul nerabi I i ty assessments i s to understand the nature and degree to whi ch 
organizations, mission/busi ness processes, and information systems are vulnerable to threat 
sources and the threat events can be initiated by those threat sources. Vulnerabilities can be 
pervasi ve across organi zati ons and can have wi de-rangi ng adverse i impacts i f expl oi ted by threat 
events. For example, organizational failure to consider supply chain activities can result in 
organi zati ons acquiring subverted components that adversaries could exploit to disrupt 
organizational mi ssion^busi ness functions or obtain sensitive organizational information. 

3-2: Determi ne L i kel i hood - Determi ne the I i kel i hood that threat events of concern result i n adverse 

impacts, considering: (1) the characteristics of the threat sources that could initiate the events; (2) 
the vulnerabilities/predisposing conditions identified; and (3) the organizational susceptibility 
reflecting the safeguard^countermeasures planned or implemented to impede such events. 

Organi zati ons empl oy a three-step process to determi ne the overal 11 i kel i hood of threat events. 
First, organi zati ons assess the likelihood that threat events will be initiated (for adversarial threat 
events) or will occur (for non-adversarial threat events). Second, organi zati ons assess the 
likelihood that threat events, once initiated or occurring, will result in adverse i impacts to 
organizational operations and assets, individuals, other organizations, or the Nation. Finally, 
organi zati ons assess the overal I I i kel i hood as a combi nati on of I i kel i hood of i nitiati on/occurrence 
and likelihood of resulting in adverseiimpact. 

Organi zati ons assess the I i kel i hood of threat event i ni ti ati on by taki ng i nto consi derati on the 
characteristics of the threat sources of concern including capability, intent, and targeting. If threat 
events requi re more capabi I i ty than adversari es possess (and adversari es are cogni zant of thi s 
fact), then the adversari es are not expected to i niti ate the events. I f adversari es do not expect to 
achieve intended objectives by executing threat events, then the adversaries are not expected to 
initiate the events. And finally, if adversaries are not actively targeting specific organizations or 
their mission^busi ness functions, adversaries are not expected to initiate threat events. 


3-3: Determine I impact - Determine the adverse i impacts from threat events of concern considering: 

(i) the characteristics of the threat sources that could initiate the events; (ii) the 
vulnerabilities/predisposing conditions identified; and (iii) the susceptibility reflecting the 
safeguard^countermeasures planned or implemented to impede such events. 
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Organi zati ons descri be adverse i mpacts i n terms of the potenti al harm caused to organi zati onal 
operations and assets, individuals, other organizations, or the Nation. Where the threat event 
occurs and whether the effects of the event are contai ned or spread, i nfI uences the severity of the 
impact. Assessing impact can involve identifying assets or potential targets of threat sources, 
including information resources (e.g., information, data repositories, information systems, 
applications, information technologies, communications I inks), people, and physical resources 
(e.g., buildings, power supplies), which could be affected by threat events. 

3-4: Determine Risk - Determine the risk to the organi zati on from threat eventsof concern 

consi deri ng: (1) the i impact that woul d resul t from the events; and (2) the I i kel i hood of the events 
occurring. 

Organi zati ons assess the risks from threat events as a combi nation of likelihood and impact. The 
level of risk associated with identified threat events represents a determination of the degree to 
whi ch organi zati ons are threatened by such events. Organi zati ons make expl i ci t the uncertai nty i n 
the risk determinations, including, for example, organizational assumptions and subjective 
judgment^decisions. Organizations can order the list of threat events of concern by the level of 
risk determined during the risk assessment—with the greatest attention going to high-risk events. 
Each risk corresponds to a specific threat event with a level of impact if that event occurs. In 
general, the risk I evel is typical Iy not higher than the i impact Ievel, and I i kel ihood can serve to 
reduce risk below that impact level. 

The Risk Assessment Report (RAR) includes the foil owing “minimum” sections. 

• System Characterization 

• Threat Areas 

• Severi ty of FI PS 199 I mpacts of Conf i denti al, I ntegri ty and Avai I abi I i ty (based on 
the Securi ty Categori zati on) 

• ThreatA/ ul nerabi lity Pai rs 

• Ri sk Cal cul ati on (I i kel i hood occurrence of threats/vul nerabi I ities bei ng expl oited) 

• Ri sk Summary/Recommendati ons (for each subsystem def i ni ti on of the 
Vulnerability/Security Concern and NIST 800-53 Security Controls) 

The effectiveness of risk assessment results is in part determined by the abi lity of decision makers 
to determine the continued applicability of assumptions made as part of the assessment. 
Information related to uncertainty is compiled and presented in a manner that readily supports 
informed risk management decisions. 

3-5: Develop a Security Reference Architecture (SRA) 6 - Based on the results of steps 3-1 to 3-4 

and the Risk Assessment Report (RAR), develop an SRA that provides an authoritative source of 
information about a specific vehicle subject area (e.g., safety and non-safety zones). This will 
hel p gui de and constrai n the representati ons of mul ti pi e archi tectures and sol uti ons. 


6 This task was added to the application of the NIST RMF due to its importance in supporting the development of vehicle 
cybersecurity requirements. 
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A SRA serves as a reference foundati on for architectures and sol uti ons and may al so be used for 
comparison and alignment purposes. A reference architecture provides a tempi ate, often based on 
the generalization of a set of solutions. These solutions may have been generalized and structured 
for the depiction of one or more architecture structures, based on the harvesting of a set of 
patterns that have been observed in a number of successful implementations. Furthermore, it 
shows how to compose these parts together i nto a sol uti on. Reference architectures can represent 
a parti cul ar domai n or a sped f i c proj ect. For exampl e, A UTOSA R 7 i s a component-based 
reference architecture for automotive software architectures. 

A SRA typically would group functions, such as vehicle (infotainment, brakes, powertrain), into 
high, medium, and low security zones based on criticality (e.g., safety). 

A SRA commonly provides the foil owing attributes. 

• common securi ty I anguage for the vari ous stakehol ders 

• consi stency of i mpl ementati on of technol ogy to sol ve probl ems 

• support of the val i dati on of sol uti ons agai nst proven reference archi tectures 

• securi ty techni cal gui dance and standards, based on sped f i ed pri nci pi es that need to be 
f ol I owed and i mpl emented as part of the sol uti on 

Examples of Security Architectures include: 

• DoD Goal Security Architecture (DGSA), 

• Open Management Group (OMG) Common Data Security Architecture, and 

• Network Centric Operations and Warfare (NCOW) Reference Model. 


Figures 3 and 4 below show notional depictions of a reference architecture. Figure 3 depicts a diagram 
showing that a Reference Architecture is an authoritative source of information about a specific subject 
area gui di ng and constrai ni ng the i nstanti ati ons of mul ti pi e archi tectures and sol uti ons. Fi gure 4 depi cts a 
reference architecture for e-Enabled aircraft/avionics 8 specifically. ThisAircraft Information 
Domains and Interconnections Reference Architecture is neither binding for future aircraft 
architectures nor a representation of any existing aircraft architecture. The aircraft domai ns are 
among other thi ngs, a means for organizi ng the approach to the probl em of appl yi ng modern 
networking technology and security. The aggregation and identification of “closed,” “private,” 
and “ publ i c” characteri sti cs of the domai ns are used to di scuss attri butes rel ati ng to system 
properties. 


7 Automotive Open System Architecture (AUTOSAR). www.autosar.org/= 

o 

Figure 3 was created from information derived from Aeronautical Radio, Inc.’s, Draft2-ARINC Project Paper 811, 
Commercial Aircraft Information Security, Concepts of Operation and Process Framework, Figure, 2, July 22,2005. 
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Reference Architecture 


Guides and constrains 
the development of 


Stakeholder lnpul,or 
Requirements 


Figure3: Depiction of ReferenceArchitecture 




Figure4: Aircraft Information Domainsand Interconnections Reference Architecture 


RMF Step 4: Implement Security Controls 

4-1: Common Control Identification - Identify the security controlsthat are provided by the 

organization as common controls for organizational information systems and document the 
controls in a security plan (or equivalent document). 
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Common control s are securi ty control s that are i nheri ted by one or more organi zati onal 
information systems. Common controls are identified by the chief information officer and/or 
senior information security officer in collaboration with the information security architect and 
assigned to specific organizational entities (designated as common control providers) for 
development, implementation, assessment, and monitoring. Common control providers may also 
be i nformati on system owners when the common control s are resi dent withi n an i nf ormati on 
system. 

4-2: Security Control Selection - Select the security controls for the information system and 

document the controls in the security plan. 

The securi ty control s are sel ected based on the securi ty categori zati on of the i nformati on system. 
The security control selection process includes, as appropriate: (1) choosing a set of baseline 
security controls; (2) tailoring the baseline security controls by applying scoping, 
parameterization, and compensating control guidance; (3) supplementing the tailored baseline 
security controls, if necessary, with additional control sand/or control enhancements to address 
unique organizational needs based on a risk assessment (either formal or informal) and local 
conditions including environment of operation, organization-specific security requirements, 
specific threat information, cost-benefit analyses, or special circumstances; and (4) specifying 
mi ni mum assurance requi rements, as appropriate. 

4-3: Security Test and Evaluation/Penetration Testing 9 - The organization requiresthat 

i nformati on/control system devel opers create a Securi ty Test and Eval uati on (ST & E) R an, 
implement the plan, and document the results. Security testing is conducted at the system and 
component levels for vehicles. 

To suppl ement ST& E, the organi zati on shoul d perform penetrati on testi ng on the vehi cl e control 
systems, especially external interfaces(e.g., telemetry, infotainment). Penetration testing is a 
method of evaluating the security of a computer system or network by simulating an attack from 
malicious outsiders (who do not have an authorized means of accessing the organization's 
systems) and malicious insiders (who have some level of authorized access). The process 
involves an active analysis of the system for any potential vulnerabilities that could result from 
poor or improper system configuration, both known and unknown hardware or software flaws, or 
operational weaknesses in process or technical countermeasures. 

Developmental security test results are used to the greatest extent feasible after verification of 
the results and recognizi ng that these results are i mpacted whenever there have been security 
relevant modifications to the control system subsequent to developer testing. Test results may be 
used in support of the security certification process for the delivered information/control system. 


9 

This task was added to the application of the NIST RMFdueto its importance in supporting the development of vehicle 
cybersecurity requirements. 
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RMF Step 5: Assess Security Controls 


5-1: Management Risk Assessment Review - Communicate risk assessment results to organizational 

decision makers to support risk responses. 

Organizations can communicate risk assessment results in a variety of ways (e.g., executive 
briefings, risk assessment reports, dashboards). Such risk communications can be formal or 
informal with the content and format determined by organizations initiating and conducting the 
assessments. Organi zati ons provi de gui dance on sped f i c ri sk communi cati on and reporti ng 
requirements, included as part of preparing for the risk assessment (if not provided in the risk 
management strategy as part of the risk framing task). 


5-2: Risk Assessment I nformation Sharing- Share risk-related information produced during the risk 

assessment with appropriate organizational personnel. 

Organi zati ons share source i nf ormati on and i ntermedi ate resul ts and provi de gui dance on shari ng 
risk-related information. Information sharing occurs primarily within organizations, via reports 
and briefings, and by updating risk-related data repositories with supporting evidence for the risk 
assessment results. Information sharing is also supported by documenting the sources of 
information, analytical processes, and intermediate results, so that risk assessments can be easily 
maintained. Information sharing may also occur with other organizations. 

RMF Step 6: Monitor Security Controls 


6-1: Risk Factor Monitoring - Conduct ongoing monitoring of the risk factors that contribute to 

changes in risk to organizational operations and assets, individuals, other organizations, or the 
Nation. 

Organi zati ons moni tor ri sk factors of i importance on an ongoi ng basi s to ensure that the 
information needed to make credible, risk-based decisions continues to be avail able over time. 
Monitoring risk factors (e.g., threat sources and threat events, vulnerabilities and predisposing 
conditions, capabilities and intent of adversaries, targeting of organizational operations, assets, or 
individuals) can provide critical information on changing conditions that could potentially affect 
the ability of organi zati ons to conduct core missions and business functions. Information derived 
from the ongoi ng moni tori ng of ri sk factors can be used to refresh ri sk assessments at whatever 
frequency deemed appropriate. 

6-2: Risk Assessment Updates: - Update existing risk assessment using the results from ongoing 

monitoring of risk factors. 

Organi zati ons determi ne the frequency and the ci rcumstances under whi ch ri sk assessments are 
updated. Such determi nations can include, for example, the current level of risk to and/or the 
importance of, core organizational mission^business functions. If significant changes (as defined 
by organi zati onal pol i ci es, di recti on, or gui dance) have occurred si nee the ri sk assessment was 
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conducted, organizations can revisit the purpose, scope, assumptions, and constraints of the 
assessment to determi ne whether al I tasks i n the ri sk assessment process need to be repeated. 
Otherwise, the updates constitute subsequent risk assessments, identifying and assessing only 
how selected risk factors have changed, for example: (1) the identification of new threat events, 
vulnerabilities, predisposing conditions, undesirable consequences and/or affected assets; and (2) 
the assessments of threat source characteristics (e.g., capability, intent, targeting, range of 
effects), likelihoods, and impacts. Organizations communicate the results of subsequent risk 
assessments to entities across all risk management tiers to ensure that responsible organizational 
of f i ci al s have access to cri ti cal i nf ormati on needed to make ongoi ng ri sk-based deci si ons. 

6-3: Monitoring Strategy - Develop a strategy for the continuous monitoring of security control 

effectiveness and any proposed/actual changes. 

A critical aspect of risk management isthe ongoing monitoring of security controls employed 
within or inherited by the information system. An effective monitoring strategy is developed early 
in the system development life cycle (i.e., during system design or COTS procurement decision) 
and can be included in the security plan. The implementation of a robust continuous monitoring 
program al I ows an organi zati on to understand the securi ty state of the i nf ormati on system over 
time and maintain the initial security authorization in a highly dynamic environment of operation 
with changing threats, vulnerabilities, technologies, and mission^busi ness functions. 


4.0 Observations 

This paper revi ewed the NI ST RM F gui del i nes and f oundati onal publ i cati ons for cybersecuri ty ri sk 
management and it provides a “primer” that examines cybersecurity risk management topics. Below are 
some overal I poi nts about the NI ST RM F gui del i nes as appl i cabl e to modern vehi cl es (passenger) that 
must be considered: 

• The NIST RMF is intended to support atypical IT system where vehicles are basically “control 
systems.” In a braking system (control system) information about whether brakes have been 
appl i ed i s onl y and 11 ary to whether the pads are physi cal I y appl yi ng pressure to the di sc. Getti ng 
to a I evel of detai I to cover al I the condi ti ons that make the appl i cati on of brakes and the 

i nf ormati on about that appl i cati on equal is extremel y ti me-consumi ng and may requi re more 
detai I ed gui del i nes for control systems than are provi ded by the NI ST RM F. 

• The use of FI PS 199 wi 11 not I i kel y be eff ecti ve for a vehi cl e ri sk assessment. Categori zi ng the 
i nf ormati on system has been a cri ti cal topi c for other control systems I i ke avi ati on, SCA DA 
systems, etc. The i ssue stems from the fact that a ground vehi cl e or ai rcraft i s not an i nf ormati on 
system but more a col I ecti on of compl ex i nteracti ons of many control systems at vari ous degrees 
of criticality. Security categorization approaches such as FIPS 199 used a high water mark 
approach requi ri ng al I i nteracti ons i n the system to be control I ed at the hi ghest I evel. A modern 
transportati on system such as an ai rcraft or I i ght passenger vehi cl e cannot be vi ewed as si ngl e 
purpose information system and is extremely complex, requiring alternative approaches to FIPS 
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199 for the security categorization step. As vehicle examples, you may not protect listening to the 
radi o i n the same way as operati ng the brakes. The di fferences, between the vehi cl e sector and 
typical IT enterprise systems (the NIST RMF is designed for common IT systems/applications), is 
the vehicle sector has the need to conduct security risk analysis at the “component” level (e.g., 
brakes) which have many inter-relationships with other vehicle components (e.g., powertrain, 
throttle, adaptive cruise control) and the NIST RMF does not provide the granularity to conduct 
the detailed analysis. An alternative to security categorization levels is the concept of Security 
Assurance Levels (SALs) that could be an ancillary to ISO 26262 Automotive Safety Integrity 
Levels (ASILs). The NIST paper titled Security Assurance Levels: A Vector Approach to 
Descri bi ng Security Requi rements descri bes the vector concept based on the work that has been 
developed within the International Society of Automation’s committee (ISA99) on security for 
industrial automation and control systems (IACS). 

• The bottom-1 i ne consi derati on made i n thi s paper centers around the vehi cl e sector devel opment 

and use of Security Control Catalogs based on NIST SP 800-53 and SP 800-82. The Security 
Controls are the management, operational, and technical safeguards (or countermeasures) 
prescri bed for a system to protect the confi denti al ity, i ntegri ty, and avai I abi I i ty of the system and 
its information. Security Controls, also known as Security Requirements, will be needed to 
implement security controlsto protect vehicles (based on safety criticality considerations), thus 
the vehi cl e sector shoul d consi der devel opi ng a “ Security Control Catal og.” Also, the gui dance 
documents bel ow, whi ch used NI ST 800-53 as the source document, shoul d be assessed by the 
vehicle sector for consideration and taiIoring/lessons-learned (see Appendix A for web links): 

1. U .S. Department of Energy El ectri city Subsector Cybersecurity Ri sk M anagement 
Process; 

2. U.S. Nuclear Regulatory Commission (NRC) Regulatory Guide (RG) 5.71, Cyber 
Security Programs For Nuclear Facilities; 

3. NIST Sped al Publ i cati on 800-82, Gui de to I ndustri al Control Systems (ICS) 

Security: Supervisory Control and Data Acquisition (SCADA) systems, Distributed 
Control Systems (DCS), and other control system configurations, such as 
Programmable Logic Controllers (PLC); 

4. American Public Transportation Association (APTA) Control & Communications 
Security Working Group (CCSWG) Recommended Practice, Securing Control and 
Communi cati ons Systems i n Transit Envi ronments; 

5. Department of Homeland Security (DHS) Control Systems Security Program (CSSP) 
Catalog of Control Systems Security: Recommendations for Standards Developers; 
and 

6. ARINC Technical Application Bulletin: ARINC Abn035A, Consi derati ons for the 
Incorporation of Cyber Security in the Development of Industry Standards. 
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